The Manifesto for Agile Software
Development
We are uncovering better ways of developing software by doing it and helping
others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over
comprehensive documentation Customer collaboration over contract negotiation
Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on
the left more. For more information see the link in the "See
Also" section on this page.
Focus on Quality
Software quality is a mindset. To achieve quality is the
job and focus of every member of the team. Teams should take a pragmatic
approach to quality assurance; that is, do what works even if it is low tech!
Teams that make a commitment to quality catch problems early in the software
development cycle when they cost the least.
Embrace Change
Traditional software development teams define interaction with
the business owners through contracts. This idea must be smashed!
Scrum teams embrace change. Backlog items within a sprint can be easily
replaced with other backlog items of equal effort. If a backlog item has
been started and needs to be replaced or if new backlog items will significantly
change the sprint schedule, the team comes together with the business users to
decided the course of action to take. Remember there are two finite
resources for the sprint, time and resources. Trust must be built with the
business users so that a true team environment with the needed give and take can
be created.
Coaching, not Managing
Traditional development team have one or more managers who
make all of the decisions for the team. Often these managers have little
or no background in development technology. The scrum master's sole job is
to make the team more effective. To do this, he or she removes any road
blocks that the team faces. While the goal is self managing teams,
we are practical. Teams have different skill and experience levels and
thus need different levels of direction from the scrum master. Do what
works best for the team, but work towards self managing teams.
Communicate, Communicate, Communicate... and then Communicate some more!
One of the main reasons that projects fail is a lack of
communication. Communication barriers make teams ineffective. Teams
are redefined to include the business owners as well as the developers, testers
and business analysts. Teams are located as close together as possible or
use technology that enables instant communication. Visibility into the
development process is encouraged and facilitated by all members of the team.
|